The present invention relates generally to information processing systems and more particularly to a methodology and implementation for finding references to objects in a distributed object-oriented network environment.
The development of application and system software for information processing systems has traditionally been a time-consuming and somewhat repetitive task, with software developers often having to write and re-write code to perform well known user interface and system functions in addition to writing the code optimized to implement the desired new functionality. Object-oriented programming (OOP) has emerged as a dominant programming paradigm that enables the rapid development and implementation of functionality while permitting the customization and re-use of software xe2x80x9cobjectsxe2x80x9d.
The power of OOP as a software development philosophy is realized chiefly through object frameworks which provide a collection of base object classes that can be selectively utilized by a system developer to create a software system, much like a hardware developer might construct a desktop computer from standard hardware components. Object frameworks are particularly advantageous when utilized within a distributed computing environment in which multiple, and possibly heterogeneous or dissimilar computer systems are interconnected to allow system hardware and software resources to be shared between computer systems. In order to permit programs written in multiple diverse languages to utilize object classes defined within a single object framework, it is necessary to develop a minimum level of object standardization to enable the inter-operability of object-oriented software. One organization that is working to establish industry guidelines and object management specifications to provide a common object framework for application development is the Object Management Group (OMG).
The specifications promulgated by the OMG enable the reusability, portability and interoperability of object-based software in heterogeneous distributed computing environments. An example of a commercially available object framework that conforms to OMG specifications is contained in the WebSphere Enterprise Edition Component Broker, Version 3.0, available from International Business Machines Corporation.
The OMG is an international consortium of organizations involved in various aspects of client/server computing on heterogeneous platforms such as shown in FIG. 1. The OMG has set forth published standards by which clients communicate in OOP form with servers. As part of these standards, an Object Request Broker has been defined as part of the Common Object Request Broker Architecture (CORBA). CORBA defines the object-oriented bridge between the client and the server. The object request broker (ORB) de-couples the client and server applications from the object-oriented implementation details.
The OMG defines an industry standard for xe2x80x9cObject Servicesxe2x80x9d in a document referred to as xe2x80x9cCORBAservices: Common Object Services Specificationxe2x80x9d, which is included herein by reference. The OMG Object Services Specification includes a series of chapters specifying a variety of services for use in CORBA systems. Such service specifications include, inter alia, a xe2x80x9cNaming Servicexe2x80x9d Specification 97-12-10, and xe2x80x9cLife Cycle Servicexe2x80x9d Specification 97-12-13.
In a distributed object-oriented environment, there is a need to be able to locate references to objects. The OMG Naming Service provides such a mechanism, by allowing an object to be located by the use of a human-readable name. A naming service provides a one-to-one mapping from a human-readable name to an object instance.
Another mechanism provided to locate object references in a distributed object-oriented environment is by use of the FactoryFinder interface defined in the OMG Life Cycle Service. A FactoryFinder provides a standard service that can be utilized by applications to locate a Factory object, i.e. an object that is used to create instances of other objects, within the heterogeneous distributed object-oriented computing environment. The Life Cycle Service provides a mechanism for finding factories anywhere in a distributed environment, where the factories are identified by the interface supported by the objects which the factories create rather than by a simple name.
In an environment where both Naming and Life Cycle FactoryFinder services are provided (such as the OMG CORBA programming model), both services are often used together to enable a client or user to locate object factories. The client uses the Naming Service to locate a Life Cycle Service FactoryFinder object, and then uses the FactoryFinder object to locate an object factory.
Another major force within the distributed object-oriented industry are the Java specifications from Sun Microsystems. Among the specifications provided is xe2x80x9cThe Enterprise JavaBeans Specification, Version 1.0xe2x80x9d which provides a server-side architecture for the deployment of objects in a distributed object-oriented environment. Also, there is a xe2x80x9cJava Naming and Directory Interface, Application Programming Interface (JNDI API)xe2x80x9d specification that provides interfaces which allow Java objects to make use of various Naming and Directory implementations. Thirdly, there is the xe2x80x9cEnterprise Java Beans to CORBA Mapping, Version 1.0xe2x80x9d Specification. These specifications define how JNDI can be used to find factories for Enterprise JavaBeans. The WebSphere Enterprise Edition Component Broker Version 3.0 from IBM (mentioned earlier as providing an available implementation of CORBA) is also an example of a commercially available implementation of these Java specifications.
To further elaborate, the EJB specification defines an interface called a xe2x80x9cHomexe2x80x9d that serves as a factory for EJB objects. The specification defines how to use JNDI to find references to Homes in the distributed object-oriented environment. A common approach to implementation of naming services in an EJB environment is to have the JNDI interface layered over the OMG Naming Service. An implementation of JNDI done in this way is referred to as a CosNaming plug-in. The xe2x80x9cEnterprise Java Beans to CORBA Mapping, Version 1.0xe2x80x9d specification gives specific guidance for the layout of an OMG name space for the bindings to EJBHomes when used by a CosNaming plug-in.
The Java specifications do not provide for a service similar to the Life Cycle Service defined by the OMG. However, in a distributed object-oriented environment, there are advantages to using Life Cycle Services rather than Naming Services to locate object factories. Because FactoryFinder objects find object factories based on specified selection criteria (i.e. type of objects the factory creates) rather than by specific name, FactoryFinders provide a level of indirection between the client and the dynamically changing distributed environment in which the object factories exist. Thus, instead of finding a specifically named object as is done in a naming service, a FactoryFinder finds object factories that meet the specified input criteria. This level of indirection enables more complex distribution scenarios while protecting the client code from having to change whenever the environment is reconfigured and additional named objects are installed.
In co-pending applications, Ser. No. 09/605,779 and Ser. No. 09/605,780, which are both included herein by reference, there is disclosed, inter alia, a mechanism which allows code that needs to find EJBHomes to have the advantages of a Life Cycle Service FactoryFinder, including being protected from change when the configuration changes. However, using that methodology, the FactoryFinder parameters are used rather than fully qualified EJBHome names. Thus, the use of the FactoryFinder methodology is exposed to the user since, even though Naming interfaces are used, the syntax of the parameters passed must conform to the rules for FactoryFinders.
Further, even though the FactoryFinder methodology protects source code used to find EJBHomes from needing to be changed when changes in the configuration occur in a specific environment where those enterprise beans are deployed, it is noted that enterprise beans are intended to be deployed in more than one environment. For example, during the development and testing of an EJB-based application, the enterprise beans may be deployed first in a unit-testing environment, then in an integration-testing environment, followed by a system-testing environment and finally into a production system. In addition, that same EJB-based application may be deployed into different production systems which may have different characteristics. Some of the test environments or alternate production environments may not even provide factory finding capabilities. Therefore it is highly likely that, using the above methodology, the name will have to be changed as the code is progressed from development, through testing and into production, or when migrated from one production environment to another. In some cases, where factory finding is available in both environments, the path from the root of the name space to where the FactoryFinder is bound would need to be changed. In addition, when one of those environments does not provide factory finding capability, a fully qualified name for the EJBHome from the root of the name space would need to be used. In an EJB-based application, there may be many places where enterprise beans need to find the EJBHomes of other enterprise beans. The need for source code changes in many enterprise beans at each of these stages introduces a process that is not only time consuming and tedious, but is also inherently error-prone.
Thus, there is a need for an improved methodology and implementing system where Naming interfaces can be used for finding EJBHomes using Life Cycle semantics without exposing Life Cycle to the user, and while satisfying the intent of the previously mentioned EJB specifications. There is a further need to provide such a methodology and implementing system which allows the deployment of the enterprise beans in different environments and during different stages of the development cycle without requiring source code changes to be made.
A method and implementing system are provided to enable EJBHomes to be found using Naming interfaces and fully qualified EJBHome names while making use of Life Cycle factory finding semantics. Means are provided to allow the enterprise beans to be deployed in different environments without source code changes, including environments which would require the reconfiguration of the FactoryFinder being used and environments that don""t provide factory finding capabilities.